Протоколирование пакетов
TMeter позволяет вести протокол пакетов, попавших в фильтр. Для этого каждый фильтр имеет свой независимый коллектор пакетов. Коллектор - это специальное "хранилище" для пакетов. Хранить информацию о каждом собранном пакете неразумно, т.к. для каждого сеанса связи пакеты, как правило, имеют общие характеристики (например, протокол, адрес источника и назначения и т.п.). Поэтому пакеты в коллекторе собираются в специальные "ячейки" или "позиции". Размер коллектора задается в позициях. Каждая позиция хранит следующую информацию о пакетах попавших в фильтр:
- тип протокола
- адрес и порт отправителя
- адрес и порт получателя
- размер переданных и принятых байт
Коллектор пакетов каждого фильтра, в свою очередь, состоит из двух частей - realtime-коллектора и flush-коллектора. В Realtime-коллектор помещаются собранные пакеты которые удовлятворяют по-крайней мере одному правилу входящему в фильтр. Размер realtime-коллектора задает пользователь в редакторе фильтра (от 100 до 1000 позиций). Всегда следует помнить, что большой размер коллектора пакетов (более 800 позиций) и высокая интенсивность попаданий пакетов в фильтр понижает производительность системы, т.к. при каждом попадании пакета в фильтр просматривается весь коллектор на предмет поиска подходящей позиции для пакета. Если свободной позиции для нового пакета в realtime-коллекторе не обнаружено, то это означает "переполнение realtime-коллектора". Переполнение realtime-коллектора означает, что часть информации о пакетах, попавших в фильтр будет утеряна. Поэтому, при регулярном переполении realtime-коллектора его размер можно увеличить или уменьшить интервал записи коллектора.
При наступлении события, называемого "сбросом коллектора" в файл или в базу данных, содержимое realtime-коллектора копируется в flush-коллектор. Далее содержимое realtime-коллектора очищается, а содержимое flush-коллекторa записывается в файл или в базу данных. В случае удачной записи flush-коллектора его содержимое очищается и он готов к приему очередной порции данных из realtime-коллектора. Если содержимое flush-коллектора записать не удалось по какой-либо причине (например, связь с базой данных потеряна), то несохранненные данные из flush-коллектора будут записаны при наступлении следующего события "сброс коллектора". Размер flush-коллектора - 2000 позиций.
При записе в файл необходимо в окне редактирования фильтра задать шаблон файлов для протоколирования пакетов. Поскольку каждый фильтр имеет свой независимый коллектор пакетов, поэтому шаблоны файлов должны быть уникальны для каждого фильтра.
Пример файла с протоколом пакетов показан ниже. Строки, начинающиеся с "---" содержат временную метку сброса коллектора пакетов в данный файл. Далее идут непосредственно данные о сетевых пакетах, которые попали в фильтр за время от последнего сброса коллектора. Первое поле - тип протокола, второе и третье поле - адрес и порт источника, четвертое и пятое поле - адрес и порт получателя, шестое и седьмое поле - количество переданных и принятых байт соответственно.
--- Time: 2001-09-12 11:32:54 TCP 192.168.190.62 2532 192.168.190.11 143 1174 1492 TCP 192.168.190.62 2533 192.168.190.11 143 450 811 TCP 192.168.190.62 2534 192.168.190.11 143 471 636 TCP 192.168.190.62 2535 192.168.190.11 143 453 809 --- Time: 2001-09-12 11:33:06 TCP 192.168.190.62 2502 192.168.190.11 3128 80 3033 TCP 192.168.190.62 2537 192.168.190.11 3128 562 1562 TCP 192.168.190.62 2538 192.168.190.11 3128 547 1562 TCP 192.168.190.62 2539 192.168.190.11 3128 557 1562 --- Time: 2001-09-12 11:34:42 TCP 192.168.190.62 2502 192.168.190.11 3128 80 1541 TCP 192.168.190.62 2540 192.168.190.11 3128 557 1562 TCP 192.168.190.62 2541 192.168.190.11 3128 615 1562
Режим компрессии непривилегированнных портов
Как видно из примера лог-файла пакетов выше, открытие одной web-странички в Интернет-браузере приводит к установлении нескольких TCP-соединений одновременно. Поэтому, чтобы сократить объем протоколируемой информации, TMeter применяет так называемый режим "компрессии непривилегированных портов". Суть его в следующем. Как известно, существует два типа TCP- и UDP-портов: "привилегированные" (порты с номерами от 0 до 1023) и "непривилегированные" (порты с номерами от 1024 до 65535). Как правило, привилегированные порты используют различные сервисы (например, порт 80 - протокол http, порт 53 - протокол DNS), а непривилегированные порты используются клиентскими программами. В режиме компрессии непривилегированных портов во всех соединениях типа "клиент-сервер" клиентский порт будет заменяться на число 65535. Это число указывает на то, что один из участников соединения использовал клиентские порты (1024-65535). Таким образом, привеленный выше фрагмент лог файла будет сжат:
--- Time: 2001-09-12 11:32:54 TCP 192.168.190.62 65535 192.168.190.11 143 2548 3748 --- Time: 2001-09-12 11:33:06 TCP 192.168.190.62 65535 192.168.190.11 3128 142 7539 --- Time: 2001-09-12 11:34:42 TCP 192.168.190.62 65535 192.168.190.11 3128 123 4598
Отменить использование режима компрессии непривилегированных портов можно прописав параметр NoCompressNonPrivilegedPorts=1 в секцию описания фильтра tmf-файла.
При записи пакетов в базу данных необходимо создать OLE DB инитстроку подключения к базе данных и таблицу в базе данных. TMeter сам создавать таблицу в базе данных не умеет. Для более подробной информации о настройке подключения к базе данных см. документ "Протоколирование пакетов в базу данных".